3.1. Cobbler Primitives¶

Primitives are the building blocks Cobbler uses to represent builds, as outlined in the “How We Model Things” section of the :ref:`Introduction to Cobbler <about>`_ page. These objects are generally loosely related, though the distro/profile/system relation is somewhat more strict.

This section covers the creation and use of these objects, as well as how they relate to each other - including the methodology by which attributes are inherited from parent objects.

3.1.1. Standard Rules¶

Cobbler has a standard set of rules for manipulating primitive field values and, in the case of distros/profiles/systems, how those values are inherited from parents to children.

3.1.1.1. Inheritance of Values¶

Inheritance of values is based on the field type.

For regular fields and arrays, the value will only be inherited if the field is set to <<inherit>>. Since distros and other objects like repos do not have a parent, these values are inherited from the defaults in Cobbler Settings. If the field is specifically set to an empty string, no value will be inherited.
For hashes, the values from the parent will always be inherited and blended with the child values. If the parent and child have the same key, the child’s values will win an override the parent’s.

3.1.1.2. Array Fields¶

Some fields in Cobbler (for example, the --name-servers field) are stored as arrays. These arrays are always considered arrays of strings, and are always specified in Cobbler as a space-separated list when using add/edit.

Example:

$ cobbler [object] edit --name=foo --field="a b c d"

3.1.1.3. Hash Fields (key=value)¶

Other fields in Cobbler (for example, the –ksmeta field) are stored as hashes - that is a list of key=value pairs. As with arrays, both the keys and values are always interpreted as strings.

3.1.1.3.1. Preserving Values When Editing¶

By default, any time a hash field is manipulated during an edit, the contents of the field are replaced completely with the new values specified during the edit.

Example:

$ cobbler distro edit --name=foo --ksmeta="a=b c=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd'}
$ cobbler distro edit --name=foo --ksmeta="e=f"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'e': 'f'}

To preserve the contents of these fields, –in-place should be specified:

$ cobbler distro edit --name=foo --ksmeta="a=b c=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd'}
$ cobbler distro edit --name=foo --in-place --ksmeta="e=f"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd', 'e': 'f'}

3.1.1.3.2. Removing Values¶

To remove a single value from the hash, use the ‘~’ (tilde) character along with –in-place:

$ cobbler distro edit --name=foo --ksmeta="a=b c=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd'}
$ cobbler distro edit --name=foo --in-place --ksmeta='~a'
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'c': 'd'}

3.1.1.3.3. Suppressing Values¶

You can also suppress values from being used, by specifying the ‘-’ character in front of the key name:

$ cobbler distro edit --name=foo --ksmeta="a=b c=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd'}
$ cobbler distro edit --name=foo --in-place --ksmeta='-a'
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'-a': 'b', 'c': 'd'}

In this case, the key=value pair will be ignored when the field is accessed.

3.1.1.3.4. Keys Without Values¶

You can always specify keys without a value:

$ cobbler distro edit --name=foo --ksmeta="a b c"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': '~', 'c': '~', 'b': '~'}

<div class=”alert alert-info alert-block”>**Note:** While valid syntax, this could cause problems for some fields where Cobbler expects a value (for example, –template-files).</div>

3.1.1.3.5. Keys With Multiple Values¶

It is also possible to specify multiple values for the same key. In this situation, Cobbler will convert the value portion to an array:

$ cobbler distro edit --name=foo --in-place --ksmeta="a=b a=c a=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': ['b', 'c', 'd']}

Note

You must specify --in-place for this to work. By default the behavior will result in a single value, with the last specified value being the winner.

3.1.2. Standard Primitive Sub-commands¶

All primitive objects support the following standard sub-commands:

3.1.2.1. List¶

The list command simply prints out an alphabetically sorted list of all objects.

Example:

$ cobbler distro list
   centos6.3-x86_64
   debian6.0.5-x86_64
   f17-x86_64
   f18-beta6-x86_64
   opensuse12.2-i386
   opensuse12.2-x86_64
   opensuse12.2-xen-i386
   opensuse12.2-xen-x86_64
   sl6.2-i386
   sl6.2-x86_64
   ubuntu-12.10-i386
   ubuntu-12.10-x86_64

The list command is actually available as a top-level command as well, in which case it will iterate through every object type and list everything currently stored in your Cobbler database.

3.1.2.2. Report¶

The report command prints a formatted report of each objects configuration. The optional --name argument can be used to limit the output to a single object, otherwise a report will be printed out for every object (if you have a lot of objects in a given category, this can be somewhat slow).

As with the list command, the report command is also available as a top-level command, in which case it will print a report for every object that is stored in your Cobbler database.

3.1.2.3. Remove¶

The remove command uses only the --name option.

Note

Removing an object will also remove any child objects (profiles, sub-profiles and/or systems). Prior versions of Cobbler required an additional --recursive option to enable this behavior, but it has become the default in recent versions so use remove with caution.

Example:

$ cobbler [object] remove --name=foo

3.1.2.4. Copy/Rename¶

The copy and rename commands work similarly, with both requiring a --name and --newname options.

Example:

$ cobbler [object] copy --name=foo --newname=bar
# or
$ cobbler [object] rename --name=foo --newname=bar

3.1.2.5. Find¶

The find command allows you to search for objects based on object attributes.

Please refer to the Command Line Search section for more details regarding the find sub-command.

3.1.2.6. Dumpvars (Debugging)¶

The dumpvars command is intended to be used for debugging purposes, and for those writing snippets. In general, it is not required for day-to-day use.

3.1.3. Cobbler Objects¶

3.1.3.1. Distros¶

The first step towards installing systems with Cobbler is to add a distribution record to cobbler’s configuration.

The distro command has the following sub-commands:

$ cobbler distro --help
usage
=====
cobbler distro add
cobbler distro copy
cobbler distro edit
cobbler distro find
cobbler distro list
cobbler distro remove
cobbler distro rename
cobbler distro report

3.1.3.1.1. Add/Edit Options¶

In general, it’s really a lot easier to follow the import workflow – it only requires waiting for the mirror content to be copied and/or scanned. Imported mirrors also save time during install since they don’t have to hit external installation sources. Please read the Import documentation for more details.

If you want to be explicit with distribution definition, however, here’s how it works:

Example:

$ cobbler distro add --name=string --kernel=path --initrd=path [options]

3.1.3.1.1.1. –name (required)¶

A string identifying the distribution, this should be something like “rhel4”.

3.1.3.1.1.2. –kernel (required)¶

An absolute filesystem path to a kernel image.

3.1.3.1.1.3. –initrd (required)¶

An absolute filesystem path to a initrd image.

3.1.3.1.1.4. –arch¶

Sets the architecture for the PXE bootloader and also controls how koan’s --replace-self option will operate.

The default setting (’standard’) will use pxelinux. Set to ’ia64’ to use elilo. ’ppc’ and ’ppc64’ use yaboot. ’s390x’ is not PXEable, but koan supports it for reinstalls.

’x86’ and ’x86_64’ effectively do the same thing as standard.

If you perform a cobbler import, the arch field will be auto-assigned.

3.1.3.1.1.5. –boot-files¶

This option is used to specify additional files that should be copied to the TFTP directory for the distro so that they can be fetched during earlier stages of the installation. Some distributions (for example, VMware ESXi) require this option to function correctly.

3.1.3.1.1.6. –breed¶

Controls how various physical and virtual parameters, including kernel arguments for automatic installation, are to be treated. Defaults to “redhat”, which is a suitable value for Fedora and CentOS as well. It means anything redhat based.

There is limited experimental support for specifying “debian”, “ubuntu”, or “suse”, which treats the kickstart file as a different format and changes the kernel arguments appropriately. Support for other types of distributions is possible in the future. See the Wiki for the latest information about support for these distributions.

The file used for the answer file, regardless of the breed setting, is the value used for --kickstart when creating the profile. In other words, if another distro calls their answer file something other than a “kickstart”, the kickstart parameter still governs where that answer file is.

3.1.3.1.1.7. –clobber¶

This option allows “add” to overwrite an existing distro with the same name, so use it with caution.

3.1.3.1.1.8. –comment¶

An optional comment to associate with this distro.

3.1.3.1.1.9. –fetchable-files¶

This option is used to specify a list of key=value files that can be fetched via the python based TFTP server. The “value” portion of the name is the path/name they will be available as via TFTP.

Please see the TFTP section for more details on using the python-based TFTP server.

3.1.3.1.1.10. –in-place¶

By default, any modifications to key=value fields (ksmeta, kopts, etc.) do no preserve the contents.

Example:

$ cobbler distro edit --name=foo --ksmeta="a=b c=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd'}
$ cobbler distro edit --name=foo --ksmeta="e=f"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'e': 'f'}

To preserve the contents of these fields, --in-place should be specified:

$ cobbler distro edit --name=foo --ksmeta="a=b c=d"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd'}
$ cobbler distro edit --name=foo --in-place --ksmeta="e=f"
$ cobbler distro report --name=foo | grep "Kickstart Meta"
Kickstart Metadata             : {'a': 'b', 'c': 'd', 'e': 'f'}

3.1.3.1.1.11. –kopts¶

Sets kernel command-line arguments that the distro, and profiles/systems dependant on it, will use during installation only. This field is a hash field, and accepts a set of key=value pairs:

Example:

--kopts="console=tty0 console=ttyS0,8,n,1 noapic"

3.1.3.1.1.12. –kopts-post¶

This is just like --kopts, though it governs kernel options on the installed OS, as opposed to kernel options fed to the installer. This requires some special snippets to be found in your kickstart template to work correctly.

3.1.3.1.1.13. –ksmeta¶

This is an advanced feature that sets variables available for use in templates. This field is a hash field, and accepts a set of key=value pairs:

Example:

--ksmeta="foo=bar baz=3 asdf"

See the section on Kickstart Templating for further information.

3.1.3.1.1.14. –mgmt-classes¶

Management classes that should be associated with this distro for use with configuration management systems.

Please see the Configuration Management section for more details on integrating Cobbler with configuration management systems.

3.1.3.1.1.15. –os-version¶

Generally this field can be ignored. It is intended to alter some hardware setup for virtualized instances when provisioning guests with koan. The valid options for --os-version vary depending on what is specified for --breed. If you specify an invalid option, the error message will contain a list of valid os versions that can be used. If you do not know the os version or it does not appear in the list, omitting this argument or using “other” should be perfectly fine. Largely this is needed to support older distributions in virtualized settings, such as “rhel2.1”, one of the OS choices if the breed is set to “redhat”. If you do not encounter any problems with virtualized instances, this option can be safely ignored.

3.1.3.1.1.16. –owners¶

The value for --owners is a space seperated list of users and groups as specified in /etc/cobbler/users.conf.

Users with small sites and a limited number of admins can probably ignore this option, since it only applies to the Cobbler WebUI and XMLRPC interface, not the “cobbler” command line tool run from the shell. Furthermore, this is only respected when using the authz_ownership module which must be enabled and is not the default.

Please see the Web Authorization section for more details.

3.1.3.1.1.17. –redhat-management-key¶

If you’re using Red Hat Network, Red Hat Satellite Server, or Spacewalk, you can store your authentication keys here and Cobbler can add the neccessary authentication code to your kickstart where the snippet named redhat_register is included. The default option specified in Cobbler Settings will be used if this field is left blank.

Please see the Tips for RHN section for more details on integrating Cobbler with RHN/Spacewalk.

3.1.3.1.1.18. –redhat-management-server¶

The RHN Satellite or Spacewalk server to use for registration. As above, the default option specified in Cobbler Settings will be used if this field is left blank.

Please see the Tips for RHN section for more details on integrating Cobbler with RHN/Spacewalk.

3.1.3.1.1.19. –template-files¶

This feature allows cobbler to be used as a configuration management system. The argument is a space delimited string of key=value pairs. Each key is the path to a template file, each value is the path to install the file on the system. Koan also can retrieve these files from a cobbler server on demand, effectively allowing cobbler to function as a lightweight templated configuration management system.

Please see the Built-In Configuration Management section for more details on using template files.

3.1.3.2. Profiles and Sub Profiles¶

A profile associates a distribution to additional specialized options, such as a kickstart automation file. Profiles are the core unit of provisioning and at least one profile must exist for every distribution to be provisioned. A profile might represent, for instance, a web server or desktop configuration. In this way, profiles define a role to be performed.

The profile command has the following sub-commands:

$ cobbler profile --help
usage
=====
cobbler profile add
cobbler profile copy
cobbler profile dumpvars
cobbler profile edit
cobbler profile find
cobbler profile getks
cobbler profile list
cobbler profile remove
cobbler profile rename
cobbler profile report

3.1.3.2.1. Add/Edit Options¶

Example:

$ cobbler profile add --name=string --distro=string [options]

3.1.3.2.1.1. –name (required)¶

A descriptive name. This could be something like “rhel5webservers” or “f9desktops”.

3.1.3.2.1.2. –distro (required)¶

The name of a previously defined cobbler distribution. This value is required.

3.1.3.2.1.3. –boot-files¶

This option is used to specify additional files that should be copied to the TFTP directory for the distro so that they can be fetched during earlier stages of the installation. Some distributions (for example, VMware ESXi) require this option to function correctly.

3.1.3.2.1.4. –clobber¶

This option allows “add” to overwrite an existing profile with the same name, so use it with caution.

3.1.3.2.1.5. –comment¶

An optional comment to associate with this profile.

3.1.3.2.1.6. –dhcp-tag¶

DHCP tags are used in the dhcp.template when using multiple networks.

Please refer to the DHCP section for more details.

3.1.3.2.1.7. –enable-gpxe¶

When enabled, the system will use gPXE instead of regular PXE for booting.

Please refer to the Using gPXE section for details on using gPXE for booting over a network.

3.1.3.2.1.9. –fetchable-files¶

This option is used to specify a list of key=value files that can be fetched via the python based TFTP server. The “value” portion of the name is the path/name they will be available as via TFTP.

Please see the TFTP section for more details on using the python-based TFTP server.

3.1.3.2.1.10. –in-place¶

By default, any modifications to key=value fields (ksmeta, kopts, etc.) do no preserve the contents. To preserve the contents of these fields, --in-place should be specified. This option is also required is using a key with multiple values (for example, “foo=bar foo=baz”).

3.1.3.2.1.11. –kickstart¶

Local filesystem path to a kickstart file. http:// URLs (even CGI’s) are also accepted, but a local file path is recommended, so that the kickstart templating engine can be taken advantage of.

If this parameter is not provided, the kickstart file will default to /var/lib/cobbler/kickstarts/default.ks. This file is initially blank, meaning default kickstarts are not automated “out of the box”. Admins can change the default.ks if they desire.

When using kickstart files, they can be placed anywhere on the filesystem, but the recommended path is /var/lib/cobbler/kickstarts. If using the webapp to create new kickstarts, this is where the web application will put them.

3.1.3.2.1.12. –kopts¶

Sets kernel command-line arguments that the profile, and sub-profiles/systems dependant on it, will use during installation only. This field is a hash field, and accepts a set of key=value pairs.

Example:

--kopts="console=tty0 console=ttyS0,8,n,1 noapic"

3.1.3.2.1.13. –kopts-post¶

This is just like --kopts, though it governs kernel options on the installed OS, as opposed to kernel options fed to the installer. This requires some special snippets to be found in your kickstart template to work correctly.

3.1.3.2.1.14. –ksmeta¶

This is an advanced feature that sets variables available for use in templates. This field is a hash field, and accepts a set of key=value pairs:

Example:

--ksmeta="foo=bar baz=3 asdf"

See the section on Kickstart Templating for further information.

3.1.3.2.1.15. –mgmt-classes, –mgmt-parameters¶

Management classes and parameters that should be associated with this profile for use with configuration management systems.

Please see the Configuration Management section for more details on integrating Cobbler with configuration management systems.

3.1.3.2.1.16. –name-servers¶

If your nameservers are not provided by DHCP, you can specify a space seperated list of addresses here to configure each of the installed nodes to use them (provided the kickstarts used are installed on a per-system basis). Users with DHCP setups should not need to use this option. This is available to set in profiles to avoid having to set it repeatedly for each system record.

3.1.3.2.1.17. –name-servers-search¶

As with the --name-servers option, this can be used to specify the default domain search line. Users with DHCP setups should not need to use this option. This is available to set in profiles to avoid having to set it repeatedly for each system record.

3.1.3.2.1.18. –owners¶

The value for --owners is a space seperated list of users and groups as specified in /etc/cobbler/users.conf

Users with small sites and a limited number of admins can probably ignore this option, since it only applies to the Cobbler WebUI and XMLRPC interface, not the “cobbler” command line tool run from the shell. Furthermore, this is only respected when using the authz_ownership module which must be enabled and is not the default.

Please see the Web Authorization section for more details.

3.1.3.2.1.19. –parent¶

This is an advanced feature.

Profiles may inherit from other profiles in lieu of specifing --distro. Inherited profiles will override any settings specified in their parent, with the exception of --ksmeta (templating) and --kopts (kernel options), which will be blended together.

Example: If profile A has --kopts="x=7 y=2", B inherits from A, and B has --kopts="x=9 z=2", the actual kernel options that will be used for B are "x=9 y=2 z=2".</p>

Example: If profile B has --virt-ram=256 and A has --virt-ram=512, profile B will use the value 256.

Example: If profile A has a --virt-file-size=5 and B does not specify a size, B will use the value from A.

3.1.3.2.1.20. –proxy¶

Specifies a proxy to use during the installation stage.

Note

Not all distributions support using a proxy in this manner.

3.1.3.2.1.21. –redhat-management-key¶

If you’re using Red Hat Network, Red Hat Satellite Server, or Spacewalk, you can store your authentication keys here and Cobbler can add the neccessary authentication code to your kickstart where the snippet named redhat_register is included. The default option specified in Cobbler Settings will be used if this field is left blank.

Please see the Tips for RHN section for more details on integrating Cobbler with RHN/Spacewalk.

3.1.3.2.1.22. –redhat-management-server¶

The RHN Satellite or Spacewalk server to use for registration. As above, the default option specified in Cobbler Settings will be used if this field is left blank.

Please see the Tips for RHN section for more details on integrating Cobbler with RHN/Spacewalk.

3.1.3.2.1.23. –repos¶

This is a space delimited list of all the repos (created with cobbler repo add and updated with cobbler reposync) that this profile can make use of during kickstart installation. For example, an example might be --repos="fc6i386updates fc6i386extras" if the profile wants to access these two mirrors that are already mirrored on the cobbler server. Repo management is described in greater depth later in the manpage.

3.1.3.2.1.24. –server¶

This parameter should be useful only in select circumstances. If machines are on a subnet that cannot access the cobbler server using the name/IP as configured in the cobbler settings file, use this parameter to override that server name. See also --dhcp-tag for configuring the next server and DHCP informmation of the system if you are also using Cobbler to help manage your DHCP configuration.

3.1.3.2.1.25. –template-files¶

This feature allows cobbler to be used as a configuration management system. The argument is a space delimited string of key=value pairs. Each key is the path to a template file, each value is the path to install the file on the system. Koan also can retrieve these files from a cobbler server on demand, effectively allowing cobbler to function as a lightweight templated configuration management system.

Please see the Built-In Configuration Management section for more details on using template files.

3.1.3.2.1.26. –template-remote-kickstarts¶

If enabled, any kickstart with a remote path (http://, ftp://, etc.) will not be passed through Cobbler’s template engine.

3.1.3.2.1.27. –virt-auto-boot¶

(Virt-only) When set, the VM will be configured to automatically start when the host reboots.

3.1.3.2.1.28. –virt-bridge¶

(Virt-only) This specifies the default bridge to use for all systems defined under this profile. If not specified, it will assume the default value in the cobbler settings file, which as shipped in the RPM is ’xenbr0’. If using KVM, this is most likely not correct. You may want to override this setting in the system object. Bridge settings are important as they define how outside networking will reach the guest. For more information on bridge setup, see the Cobbler Wiki, where there is a section describing koan usage.

3.1.3.2.1.29. –virt-cpus¶

(Virt-only) How many virtual CPUs should koan give the virtual machine? The default for this value is set in the Cobbler Settings file, and should be set as an integer.

3.1.3.2.1.30. –virt-disk-driver¶

(Virt-only) The type of disk driver to use for the disk image, for example “raw” or “qcow2”.

3.1.3.2.1.31. –virt-file-size¶

(Virt-only) How large the disk image should be in Gigabytes. The default for this value is set in the Cobbler Settings file. This can be a space seperated list (ex: “5,6,7”) to allow for multiple disks of different sizes depending on what is given to --virt-path. This should be input as a integer or decimal value without units.

3.1.3.2.1.32. –virt-path¶

(Virt-only) Where to store the virtual image on the host system. Except for advanced cases, this parameter can usually be omitted. For disk images, the value is usually an absolute path to an existing directory with an optional file name component. There is support for specifying partitions /dev/sda4 or volume groups VolGroup00, etc.

For multiple disks, seperate the values with commas such as VolGroup00,VolGroup00 or /dev/sda4,/dev/sda5. Both those examples would create two disks for the VM.

3.1.3.2.1.33. –virt-ram¶

(Virt-only) How many megabytes of RAM to consume. The default for this value is set in the Cobbler Settings file. This should be input as an integer without units, and will be interpretted as MB.

3.1.3.2.1.34. –virt-type¶

(Virt-only) Koan can install images using several different virutalization types. Choose one or the other strings to specify, or values will default to attempting to find a compatible installation type on the client system (“auto”). See the https://koan.readthedocs.io/ section for more documentation. The default for this value is set in the Cobbler Settings file.</td>

3.1.3.2.2. Get Kickstart (getks)¶

The getks command shows the rendered kickstart/response file (preseed, etc.) for the given profile. This is useful for previewing what will be downloaded from Cobbler when the system is building. This is also a good opportunity to catch snippets that are not rendering correctly.

As with remove, the --name option is required and is the only valid argument.

Example:

$ cobbler profile getks --name=foo | less

3.1.3.3. Systems¶

System records map a piece of hardware (or a virtual machine) with the cobbler profile to be assigned to run on it. This may be thought of as chosing a role for a specific system.

The system commmand has the following sub-commands:

$ cobbler system --help
usage
=====
cobbler system add
cobbler system copy
cobbler system dumpvars
cobbler system edit
cobbler system find
cobbler system getks
cobbler system list
cobbler system poweroff
cobbler system poweron
cobbler system powerstatus
cobbler system reboot
cobbler system remove
cobbler system rename
cobbler system report

Note that if provisioning via koan and PXE menus alone, it is not required to create system records in cobbler, though they are useful when system specific customizations are required. One such customization would be defining the MAC address. If there is a specific role inteded for a given machine, system records should be created for it.

System commands have a wider variety of control offered over network details. In order to use these to the fullest possible extent, the kickstart template used by cobbler must contain certain kickstart snippets (sections of code specifically written for Cobbler to make these values become reality). Compare your kickstart templates with the stock ones in /var/lib/cobbler/kickstarts if you have upgraded, to make sure you can take advantage of all options to their fullest potential. If you are a new cobbler user, base your kickstarts off of these templates. Non-kickstart based distributions, while supported by Cobbler, may not be able to use all of these features.

Example:

$ cobbler system add --name=string [--profile=name|--image=name] [options]

As you can see, a system must either be assigned to a --profile or an --image, which are mutually exclusive options.

3.1.3.3.1. Add/Edit Options¶

3.1.3.3.1.1. –name (required)¶

The system name works like the name option for other commands.

If the name looks like a MAC address or an IP, the name will implicitly be used for either --mac or --ip-address of the first interface, respectively. However, it’s usually better to give a descriptive name – don’t rely on this behavior.

A system created with name “default” has special semantics. If a default system object exists, it sets all undefined systems to PXE to a specific profile. Without a “default” system name created, PXE will fall through to local boot for unconfigured systems.

When using “default” name, don’t specify any other arguments than --profile … they won’t be used.

3.1.3.3.1.2. –profile (required, if –image not set)¶

The name of the profile or sub-profile to which this system belongs.

3.1.3.3.1.3. –image (required, if –profile not set)¶

The name of the image to which this system belongs.

3.1.3.3.1.4. –boot-files¶

This option is used to specify additional files that should be copied to the TFTP directory for the distro so that they can be fetched during earlier stages of the installation. Some distributions (for example, VMware ESXi) require this option to function correctly.

3.1.3.3.1.5. –clobber¶

This option allows “add” to overwrite an existing system with the same name, so use it with caution.

3.1.3.3.1.6. –comment¶

An optional comment to associate with this system.

3.1.3.3.1.7. –enable-gpxe¶

When enabled, the system will use gPXE instead of regular PXE for booting.

Please refer to the Using gPXE section for details on using gPXE for booting over a network.

3.1.3.3.1.8. –fetchable-files¶

This option is used to specify a list of key=value files that can be fetched via the python based TFTP server. The “value” portion of the name is the path/name they will be available as via TFTP.

Please see the TFTP section for more details on using the python-based TFTP server.

3.1.3.3.1.9. –gateway¶

Sets the default gateway, which in Redhat-based systems is typically in /etc/sysconfig/network. Per-interface gateways are not supported at this time. This option will be ignored unless --static=1 is also set on the interface.

3.1.3.3.1.10. –hostname¶

This field corresponds to the hostname set in a systems /etc/sysconfig/network file. This has no bearing on DNS, even when manage_dns is enabled. Use --dns-name instead for that feature, which is a per-interface setting.

3.1.3.3.1.11. –in-place¶

By default, any modifications to key=value fields (ksmeta, kopts, etc.) do no preserve the contents. To preserve the contents of these fields, --in-place should be specified. This option is also required is using a key with multiple values (for example, foo=bar foo=baz).

3.1.3.3.1.12. –kickstart¶

While it is recommended that the --kickstart parameter is only used within for the “profile add” command, there are limited scenarios when an install base switching to cobbler may have legacy kickstarts created on a per-system basis (one kickstart for each system, nothing shared) and may not want to immediately make use of the cobbler templating system. This allows specifing a kickstart for use on a per-system basis. Creation of a parent profile is still required. If the kickstart is a filesystem location, it will still be treated as a cobbler template.

3.1.3.3.1.13. –kopts¶

Sets kernel command-line arguments that the system will use during installation only. This field is a hash field, and accepts a set of key=value pairs:

Example:

--kopts="console=tty0 console=ttyS0,8,n,1 noapic"

3.1.3.3.1.14. –kopts-post¶

This is just like --kopts, though it governs kernel options on the installed OS, as opposed to kernel options fed to the installer. This requires some special snippets to be found in your kickstart template to work correctly.

3.1.3.3.1.15. –ksmeta¶

This is an advanced feature that sets variables available for use in templates. This field is a hash field, and accepts a set of key=value pairs:

Example:

--ksmeta="foo=bar baz=3 asdf"

See the section on Kickstart Templating for further information.

3.1.3.3.1.16. –ldap-enabled, –ldap-type¶

Cobbler contains features that enable ldap management for easier configuration after system provisioning. If set true, koan will run the ldap command as defined by the systems ldap_type. The default value is false.

3.1.3.3.1.17. –mgmt-classes and –mgmt-parameters¶

Management classes and parameters that should be associated with this system for use with configuration management systems.

Please see the Configuration Management section for more details on integrating Cobbler with configuration management systems.

3.1.3.3.1.18. –monit-enabled¶

Warning

This feature has been deprecated and will not be available in cobbler 3.0

If set true, koan will reload monit after each configuration run. The default value is false.

3.1.3.3.1.19. –name-servers¶

If your nameservers are not provided by DHCP, you can specify a space seperated list of addresses here to configure each of the installed nodes to use them (provided the kickstarts used are installed on a per-system basis). Users with DHCP setups should not need to use this option. This is available to set in profiles to avoid having to set it repeatedly for each system record.

3.1.3.3.1.20. –name-servers-search¶

As with the --name-servers option, this can be used to specify the default domain search line. Users with DHCP setups should not need to use this option. This is available to set in profiles to avoid having to set it repeatedly for each system record.

3.1.3.3.1.21. –netboot-enabled¶

If set false, the system will be provisionable through koan but not through standard PXE. This will allow the system to fall back to default PXE boot behavior without deleting the cobbler system object. The default value allows PXE. Cobbler contains a PXE boot loop prevention feature (pxe_just_once, can be enabled in /etc/cobbler/settings) that can automatically trip off this value after a system gets done installing. This can prevent installs from appearing in an endless loop when the system is set to PXE first in the BIOS order.

3.1.3.3.1.22. –owners¶

The value for --owners is a space seperated list of users and groups as specified in /etc/cobbler/users.conf.

3.1.3.3.1.23. –power-address, –power-type, –power-user, –power-password, –power-id¶

Cobbler contains features that enable integration with power management for easier installation, reinstallation, and management of machines in a datacenter environment. These parameters are described in the Power Management section under Advanced. If you have a power-managed datacenter/lab setup, usage of these features may be something you are interested in.

3.1.3.3.1.24. –proxy¶

Specifies a proxy to use during the installation stage.

Note

Not all distributions support using a proxy in this manner.

3.1.3.3.1.25. –redhat-management-key¶

If you’re using Red Hat Network, Red Hat Satellite Server, or Spacewalk, you can store your authentication keys here and Cobbler can add the neccessary authentication code to your kickstart where the snippet named “redhat_register” is included. The default option specified in Cobbler Settings will be used if this field is left blank.

Please see the Tips for RHN section for more details on integrating Cobbler with RHN/Spacewalk.

3.1.3.3.1.26. –redhat-management-server¶

The RHN Satellite or Spacewalk server to use for registration. As above, the default option specified in Cobbler Settings will be used if this field is left blank.

Please see the Tips for RHN section for more details on integrating Cobbler with RHN/Spacewalk.

3.1.3.3.1.27. –repos-enabled¶

If set true, koan can reconfigure repositories after installation.

3.1.3.3.1.28. –server¶

This parameter should be useful only in select circumstances. If machines are on a subnet that cannot access the cobbler server using the name/IP as configured in the cobbler settings file, use this parameter to override that server name. See also --dhcp-tag for configuring the next server and DHCP informmation of the system if you are also using Cobbler to help manage your DHCP configuration.

3.1.3.3.1.29. –status¶

An optional field used to keep track of a systems build or deployment status. This field is only set manually, and is not updated automatically at this time.

3.1.3.3.1.30. –template-files¶

This feature allows cobbler to be used as a configuration management system. The argument is a space delimited string of key=value pairs. Each key is the path to a template file, each value is the path to install the file on the system. Koan also can retrieve these files from a cobbler server on demand, effectively allowing cobbler to function as a lightweight templated configuration management system.

Please see the Built-In Configuration Management section for more details on using template files.

3.1.3.3.1.31. –template-remote-kickstarts¶

If enabled, any kickstart with a remote path (http://, ftp://, etc.) will not be passed through Cobbler’s template engine.

3.1.3.3.1.32. –virt-auto-boot¶

(Virt-only) When set, the VM will be configured to automatically start when the host reboots.

3.1.3.3.1.33. –virt-cpus¶

(Virt-only) The number of virtual CPUs to allocate to a system. The default for this value is set in the Cobbler Settings file, and should be set as an integer.

3.1.3.3.1.34. –virt-disk-driver¶

(Virt-only) The type of disk driver to use for the disk image, for example “raw” or “qcow2”.

3.1.3.3.1.35. –virt-file-size¶

(Virt-only) How large the disk image should be in Gigabytes. The default for this value is set in the Cobbler Settings file. This can be a space seperated list (ex: “5,6,7”) to allow for multiple disks of different sizes depending on what is given to –virt-path. This should be input as a integer or decimal value without units.

3.1.3.3.1.36. –virt-path¶

(Virt-only) Where to store the virtual image on the host system. Except for advanced cases, this parameter can usually be omitted. For disk images, the value is usually an absolute path to an existing directory with an optional file name component. There is support for specifying partitions /dev/sda4 or volume groups VolGroup00, etc.

For multiple disks, seperate the values with commas such as VolGroup00,VolGroup00 or /dev/sda4,/dev/sda5. Both those examples would create two disks for the VM.

3.1.3.3.1.37. –virt-pxe-boot¶

(Virt-only) When set, the guest VM will use PXE to boot. By default, koan will use the --location option to virt-install to specify the installer for the guest.

3.1.3.3.1.38. –virt-ram¶

(Virt-only) How many megabytes of RAM to consume. The default for this value is set in the Cobbler Settings file. This should be input as an integer without units, and will be interpretted as MB.

3.1.3.3.1.39. –virt-type¶

(Virt-only) Koan can install images using several different virutalization types. Choose one or the other strings to specify, or values will default to attempting to find a compatible installation type on the client system (“auto”). See the https://koan.readthedocs.io/ section for more documentation. The default for this value is set in the Cobbler Settings file.

3.1.3.3.2. Interface Specific Commands¶

System primitives are unique in that they are the only object in Cobbler that embeds another complex object - interfaces. As such, there is an entire subset of options that are specific to interfaces only.

3.1.3.3.2.1. –interface¶

All interface options require the use of the --interface=ifname option. If this is omitted, Cobbler will default to using the interface name “eth0”, which may not be what you want. We may also change this default behavior in the future, so in general it is always best to explicitly specify the interface name with this option.

Note

You can only edit one interface at a time! If you specify multiple --interface options, only the last one will be used.

Interface naming notes:

Additional interfaces can be specified (for example: eth1, or any name you like, as long as it does not conflict with any reserved names such as kernel module names) for use with the edit command. Defining VLANs this way is also supported, if you want to add VLAN 5 on interface eth0, simply name your interface eth0:5.

Example:

$ cobbler system edit --name=foo --ip-address=192.168.1.50 --mac=AA:BB:CC:DD:EE:A0
$ cobbler system edit --name=foo --interface=eth0 --ip-address=192.168.1.51 --mac=AA:BB:CC:DD:EE:A1
$ cobbler system report foo

Interfaces can be deleted using the --delete-interface option.

Example:

$ cobbler system edit --name=foo --interface=eth2 --delete-interface

3.1.3.3.2.2. –bonding-opts and –bridge-opts¶

Bonding and bridge options for the master-interface may be specified using –bonding-opts=”foo=1 bar=2” or –bridge-opts=”foo=1 bar=2”, respectively. These are only used if the –interface-type is a master or bonded_bridge_slave (which is also a bond master).

#### –dhcp-tag If you are setting up a PXE environment with multiple subnets/gateways, and are using cobbler to manage a DHCP configuration, you will probably want to use this option. If not, it can be ignored.

By default, the dhcp tag for all systems is “default” and means that in the DHCP template files the systems will expand out where $insert_cobbler_systems_definitions is found in the DHCP template. However, you may want certain systems to expand out in other places in the DHCP config file. Setting –dhcp-tag=subnet2 for instance, will cause that system to expand out where $insert_cobbler_system_definitions_subnet2 is found, allowing you to insert directives to specify different subnets (or other parameters) before the DHCP configuration entries for those particular systems.

3.1.3.3.2.3. –dns-name¶

If using the DNS management feature (see advanced section – cobbler supports auto-setup of BIND and dnsmasq), use this to define a hostname for the system to receive from DNS.

Example:

--dns-name=mycomputer.example.com

This is a per-interface parameter. If you have multiple interfaces, it may be different for each interface, for example, assume a DMZ/dual-homed setup.

3.1.3.3.2.4. –interface-type and –interface-master¶

One of the other advanced networking features supported by Cobbler is NIC bonding and bridging. You can use this to bond multiple physical network interfaces to one single logical interface to reduce single points of failure in your network, or to create bridged interfaces for things like tunnels and virtual machine networks. Supported values for the --interface-type parameter are “bond”, “bond_slave”, “bridge”, “bridge_slave” and “bonded_bridge_slave”. If one of the _slave options is specified, you also need to define the master-interface for this bond using --interface-master=INTERFACE.

Note

The options master and slave are deprecated, and are assumed to me bond and bond_slave when encountered. When a system object is saved, the deprecated values will be overwritten with the new, correct values.

For more details on using these interface types, please see the Advanced Networking section.

3.1.3.3.2.5. –ip-address¶

If cobbler is configured to generate a DHCP configuratition (see advanced section), use this setting to define a specific IP for this system in DHCP. Leaving off this parameter will result in no DHCP management for this particular system.

Example:

--ip-address=192.168.1.50

Note for Itanium users: This setting is always required for IA64 regardless of whether DHCP management is enabled.

If DHCP management is disabled and the interface is labelled --static=1, this setting will be used for static IP configuration.

Special feature: To control the default PXE behavior for an entire subnet, this field can also be passed in using CIDR notation. If --ip-address is CIDR, do not specify any other arguments other than --name and --profile.

When using the CIDR notation trick, don’t specify any arguments other than --name and --profile… they won’t be used.

3.1.3.3.2.6. –ipv6-address¶

The IPv6 address to use for this interface.

Note

This is not mutually exclusive with the --ipv6-autoconfiguration option, as interfaces can have many IPv6 addresses.

3.1.3.3.2.7. –ipv6-autoconfiguration¶

Use autoconfiguration mode to obtain the IPv6 address for this interface.

3.1.3.3.2.8. –ipv6-default-device¶

The default IPv6 device.

3.1.3.3.2.9. –ipv6-secondaries¶

The list of IPv6 secondaries for this interface.

3.1.3.3.2.10. –ipv6-mtu¶

Same as --mtu, however specific to the IPv6 stack for this interface.

3.1.3.3.2.11. –ipv6-static-routes¶

Same as --static-routes, however specific to the IPv6 stack for this interface.

3.1.3.3.2.12. –ipv6-default-gateway¶

This is the default gateway to use for this interface, specific only to the IPv6 stack. Unlike --gateway, this is set per-interface.

3.1.3.3.2.13. –mac-address (–mac)¶

Specifying a mac address via --mac allows the system object to boot directly to a specific profile via PXE, bypassing cobbler’s PXE menu. If the name of the cobbler system already looks like a mac address, this is inferred from the system name and does not need to be specified.

MAC addresses have the format AA:BB:CC:DD:EE:FF. It’s higly recommended to register your MAC-addresses in Cobbler if you’re using static adressing with multiple interfaces, or if you are using any of the advanced networking features like bonding, bridges or VLANs.

Cobbler does contain a feature (enabled in /etc/cobbler/settings) that can automatically add new system records when it finds profiles being provisioned on hardware it has seen before. This may help if you do not have a report of all the MAC addresses in your datacenter/lab configuration.

3.1.3.3.2.14. –mtu¶

Sets the MTU (max transfer unit) property for the interface. Normally, this is set to 9000 to enable jumbo frames, but remember you must also enable it on in your switch configuration to function properly.

3.1.3.3.2.15. –management¶

When set to true, this interface will take precedence over others as the communication link to the Cobbler server. This means it will be used as the default kickstart interface if there are multiple interfaces to choose from.

3.1.3.3.2.16. –static¶

Indicates that this interface is statically configured. Many fields (such as gateway/subnet) will not be used unless this field is enabled. When Cobbler is managing DHCP, this will result in a static lease entry being created in the dhcpd.conf.

3.1.3.3.2.17. –static-routes¶

This is a space delimited list of ip/mask:gateway routing information in that format, which will be added as extra routes on the system. Most systems will not need this information.

--static-routes="192.168.1.0/16:192.168.1.1 172.16.0.0/16:172.16.0.1"

3.1.3.3.2.18. –netmask (formerly –subnet)¶

This is the netmask of the interface, for example 255.255.255.0.

3.1.3.3.2.19. –virt-bridge¶

(Virt-only) When specified, koan will associate the given interface with the physical bridge on the system. If no bridge is specified, this value will be inherited from the profile, which in turn may be inherited from the default virt bridge configured in Cobbler Settings.

3.1.3.3.3. Get Kickstart (getks)¶

The getks command shows the rendered kickstart/response file (preseed, etc.) for the given system. This is useful for previewing what will be downloaded from Cobbler when the system is building. This is also a good opportunity to catch snippets that are not rendering correctly.

As with remove, the --name option is required and is the only valid argument.

Example:

$ cobbler system getks --name=foo | less

3.1.3.3.4. Power Commands¶

By configuring the --power-* options above, Cobbler can be used to power on/off and reboot systems in your environment.

Example:

$ cobbler system poweron --name=foo

Please see the Power Management section for more details on using these commands.

3.1.3.4. Images¶

Cobbler can help with booting images physically and virtually, though the usage of these commands varies substantially by the type of image. Non-image based deployments are generally easier to work with and lead to more sustaintable infrastructure.

3.1.3.5. Repos¶

Repository mirroring allows cobbler to mirror not only install trees (cobbler import does this for you) but also optional packages, 3rd party content, and even updates. Mirroring all of this content locally on your network will result in faster, more up-to-date installations and faster updates. If you are only provisioning a home setup, this will probably be overkill, though it can be very useful for larger setups (labs, datacenters, etc). For information on how to keep your mirror up-to-date, see Reposync.

Example:

$ cobbler repo add --mirror=url --name=string [--rpmlist=list] [--creatrepo-flags=string] \
[--keep-updated=Y/N] [--priority=number] [--arch=string] [--mirror-locally=Y/N] [--breed=yum|rsync|rhn]

3.1.3.5.1. mirror¶

The addresss of the yum mirror. This can be an rsync:// URL, an ssh location, or a http:// or ftp:// mirror location. Filesystem paths also work.

The mirror address should specify an exact repository to mirror – just one architecture and just one distribution. If you have a seperate repo to mirror for a different arch, add that repo seperately.

Example:

rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386 (for rsync protocol)
http://mirrors.kernel.org/fedora/extras/6/i386/ (for http://)
user@yourmirror.example.com/fedora-linux-core/updates/6/i386  (for SSH)

Experimental support is also provided for mirroring RHN content when you need a fast local mirror. The mirror syntax for this is --mirror=rhn://channel-name and you must have entitlements for this to work. This requires the cobbler server to be installed on RHEL5 or later. You will also need a version of yum-utils equal or greater to 1.0.4.

3.1.3.5.2. name¶

This name is used as the save location for the mirror. If the mirror represented, say, Fedora Core 6 i386 updates, a good name would be “fc6i386updates”. Again, be specific.

This name corresponds with values given to the --repos parameter of cobbler profile add. If a profile has a --repos value that matches the name given here, that repo can be automatically set up during provisioning (when supported) and installed systems will also use the boot server as a mirror (unless yum_post_install_mirror is disabled in the settings file). By default the provisioning server will act as a mirror to systems it installs, which may not be desirable for laptop configurations, etc.

Distros that can make use of yum repositories during kickstart include FC6 and later, RHEL 5 and later, and derivative distributions.

See the documentation on cobbler profile add for more information.

3.1.3.5.3. rpm-list¶

By specifying a space-delimited list of package names for --rpm-list, one can decide to mirror only a part of a repo (the list of packages given, plus dependencies). This may be helpful in conserving time/space/bandwidth. For instance, when mirroring FC6 Extras, it may be desired to mirror just cobbler and koan, and skip all of the game packages. To do this, use --rpm-list="cobbler koan".

This option only works for http:// and ftp:// repositories (as it is powered by yumdownloader). It will be ignored for other mirror types, such as local paths and rsync:// mirrors.

3.1.3.5.4. createrepo-flags¶

Specifies optional flags to feed into the createrepo tool, which is called when cobbler reposync is run for the given repository. The defaults are -c cache.

3.1.3.5.5. keep-updated¶

Specifies that the named repository should not be updated during a normal cobbler reposync. The repo may still be updated by name. The repo should be synced at least once before disabling this feature See cobbler reposync below.

3.1.3.5.6. mirror-locally¶

When set to “N”, specifies that this yum repo is to be referenced directly via kickstarts and not mirrored locally on the cobbler server. Only http:// and ftp:// mirror urls are supported when using --mirror-locally=N, you cannot use filesystem URLs.

3.1.3.5.7. priority¶

Specifies the priority of the repository (the lower the number, the higher the priority), which applies to installed machines using the repositories that also have the yum priorities plugin installed. The default priority for the plugin is 99, as is that of all cobbler mirrored repositories.

3.1.3.5.8. arch¶

Specifies what architecture the repository should use. By default the current system arch (of the server) is used, which may not be desirable. Using this to override the default arch allows mirroring of source repositories (using --arch=src).

3.1.3.5.9. yumopts¶

Sets values for additional yum options that the repo should use on installed systems. For instance if a yum plugin takes a certain parameter “alpha” and “beta”, use something like --yumopts="alpha=2 beta=3".

3.1.3.5.10. breed¶

Ordinarily cobbler’s repo system will understand what you mean without supplying this parameter, though you can set it explicitly if needed.

3.1.3.6. Management Classes¶

Management classes allow cobbler to function as a configuration management system. The lego blocks of configuration management, resources are grouped together via Management Classes and linked to a system. Cobbler supports two (2) resource types, which are configured in the order listed below:

Package Resources
File Resources

To add a Management Class, you would run the following command:

$ cobbler mgmtclass add --name=string --comment=string [--packages=list] [--files=list]

3.1.3.6.1. name¶

The name of the mgmtclass. Use this name when adding a management class to a system, profile, or distro. To add a mgmtclass to an existing system use something like (cobbler system edit --name="madhatter" --mgmt-classes="http mysql").

3.1.3.6.2. comment¶

A comment that describes the functions of the management class.

3.1.3.6.3. packages¶

Specifies a list of package resources required by the management class.

3.1.3.6.4. files¶

Specifies a list of file resources required by the management class.

3.1.3.7. File Resources¶

File resources are managed using cobbler file add, allowing you to create and delete files on a system.

3.1.3.7.1. Actions¶

3.1.3.7.1.1. create¶

Create the file. [Default]

3.1.3.7.1.2. remove¶

Remove the file.

3.1.3.7.2. Attributes¶

3.1.3.7.2.1. mode¶

Permission mode (as in chmod).

3.1.3.7.2.2. group¶

The group owner of the file.

3.1.3.7.2.3. user¶

The user for the file.

3.1.3.7.2.4. path¶

The path for the file.

3.1.3.7.2.5. template¶

The template for the file.

3.1.3.7.3. Example:¶

$ cobbler file add --name=string --comment=string [--action=string] --mode=string --group=string \
--user=string --path=string [--template=string]

3.1.3.8. Package Resources¶

Package resources are managed using cobbler package add, allowing you to install and uninstall packages on a system outside of your install process.

3.1.3.8.1. Actions¶

3.1.3.8.1.1. install¶

Install the package. [Default]

3.1.3.8.1.2. uninstall¶

Uninstall the package.

3.1.3.8.2. Attributes¶

3.1.3.8.2.1. installer¶

Which package manager to use, vaild options [rpm|yum].

3.1.3.8.2.2. version¶

Which version of the package to install.

3.1.3.8.3. Example:¶

$ cobbler package add --name=string --comment=string [--action=install|uninstall] --installer=string \
[--version=string]

3.1. Cobbler Primitives¶

3.1.1. Standard Rules¶

3.1.1.1. Inheritance of Values¶

3.1.1.2. Array Fields¶

3.1.1.3. Hash Fields (key=value)¶

3.1.1.3.1. Preserving Values When Editing¶

3.1.1.3.2. Removing Values¶

3.1.1.3.3. Suppressing Values¶

3.1.1.3.4. Keys Without Values¶

3.1.1.3.5. Keys With Multiple Values¶

3.1.2. Standard Primitive Sub-commands¶

3.1.2.1. List¶

3.1.2.2. Report¶

3.1.2.3. Remove¶

3.1.2.4. Copy/Rename¶

3.1.2.5. Find¶

3.1.2.6. Dumpvars (Debugging)¶

3.1.3. Cobbler Objects¶

3.1.3.1. Distros¶

3.1.3.1.1. Add/Edit Options¶

3.1.3.1.1.1. –name (required)¶

3.1.3.1.1.2. –kernel (required)¶

3.1.3.1.1.3. –initrd (required)¶

3.1.3.1.1.4. –arch¶

3.1.3.1.1.5. –boot-files¶

3.1.3.1.1.6. –breed¶

3.1.3.1.1.7. –clobber¶

3.1.3.1.1.8. –comment¶

3.1.3.1.1.9. –fetchable-files¶

3.1.3.1.1.10. –in-place¶

3.1.3.1.1.11. –kopts¶

3.1.3.1.1.12. –kopts-post¶

3.1.3.1.1.13. –ksmeta¶

3.1.3.1.1.14. –mgmt-classes¶

3.1.3.1.1.15. –os-version¶

3.1.3.1.1.16. –owners¶

3.1.3.1.1.17. –redhat-management-key¶

3.1.3.1.1.18. –redhat-management-server¶

3.1.3.1.1.19. –template-files¶

3.1.3.2. Profiles and Sub Profiles¶

3.1.3.2.1. Add/Edit Options¶

3.1.3.2.1.1. –name (required)¶

3.1.3.2.1.2. –distro (required)¶

3.1.3.2.1.3. –boot-files¶

3.1.3.2.1.4. –clobber¶

3.1.3.2.1.5. –comment¶

3.1.3.2.1.6. –dhcp-tag¶

3.1.3.2.1.7. –enable-gpxe¶

3.1.3.2.1.8. –enable-menu¶

3.1.3.2.1.9. –fetchable-files¶

3.1.3.2.1.10. –in-place¶

3.1.3.2.1.11. –kickstart¶

3.1.3.2.1.12. –kopts¶

3.1.3.2.1.13. –kopts-post¶

3.1.3.2.1.14. –ksmeta¶

3.1.3.2.1.15. –mgmt-classes, –mgmt-parameters¶

3.1.3.2.1.16. –name-servers¶

3.1.3.2.1.17. –name-servers-search¶

3.1.3.2.1.18. –owners¶

3.1.3.2.1.19. –parent¶

3.1.3.2.1.20. –proxy¶

3.1.3.2.1.21. –redhat-management-key¶

3.1.3.2.1.22. –redhat-management-server¶

3.1.3.2.1.23. –repos¶

3.1.3.2.1.24. –server¶

3.1.3.2.1.25. –template-files¶

3.1.3.2.1.26. –template-remote-kickstarts¶

3.1.3.2.1.27. –virt-auto-boot¶

3.1.3.2.1.28. –virt-bridge¶

3.1.3.2.1.29. –virt-cpus¶

3.1.3.2.1.30. –virt-disk-driver¶

3.1.3.2.1.31. –virt-file-size¶

3.1.3.2.1.32. –virt-path¶

3.1.3.2.1.33. –virt-ram¶

3.1.3.2.1.34. –virt-type¶

3.1.3.2.2. Get Kickstart (getks)¶

3.1.3.3. Systems¶

3.1.3.3.1. Add/Edit Options¶

3.1.3.3.1.1. –name (required)¶

3.1.3.3.1.2. –profile (required, if –image not set)¶